home *** CD-ROM | disk | FTP | other *** search
/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / source / rotate / readme < prev    next >
Encoding:
Text File  |  1994-02-03  |  4.1 KB  |  79 lines
  1.    The file you've unzipped contains 2 executable programs and the complete
  2. source code for each. The programs are meant to be examples of a fast method
  3. for rotating bitmaps. I came up with the method on my own. Though I'm sure
  4. it has been used before by other people, I've never seen it talked about or
  5. presented by anyone else.
  6.                          
  7. BITMAP.EXE -- This program pans/scales/rotates a 256x256 bitmap which is
  8. tiled over the whole screen. Though it uses 320x200 mode (13h) it maintains
  9. a 1:1 aspect ratio. The source is fully commented and meant for people to
  10. learn from. It is written in Turbo Pascal with some inline assembly, but
  11. C programmers should be able to make good sense of it. The test bitmap
  12. created by the program is stupid, but it does show what can happen to certain
  13. types of images when they are scaled down. If anyone throws in code to load
  14. a standard image file please let me know.
  15.  
  16. TILE.EXE -- This one does basically the same thing, only it uses a 32x32
  17. bitmap defined in the source which can be easily altered by anyone with
  18. the compiler. There are NO comments and the aspect ratio is not correct.
  19. The code is not well optimized, so it's slower.
  20.  
  21. Overview of rotation methods:
  22. -----------------------------
  23.    I've heard a lot of people ask how to rotate a bitmap, and there seem to
  24. be a few common methods that get brought up:
  25.  
  26. 1) Scan the source image pixel by pixel. For each one, transform the
  27.    coordinates (with a rotation matrix or whatever) and plot the pixel
  28.    at these new coordinates in the destination image. This method produces
  29.    bad images with holes, because not all pixels in the destination image
  30.    get written to.
  31.  
  32. 2) Scan the destination image pixel by pixel and 'untransform' (ie. rotate
  33.    the opposite direction) the coordinates of the pixel and use the new
  34.    coordinates to grab a pixel from the source image and copy it to the
  35.    destination. This prevent the 'holes' from appearing, because EVERY
  36.    pixel in the destination is mapped to something in the source image.
  37.  
  38. 3) Do 3 shear operations. Shearing a rectangular bitmap will turn it into
  39.    a parallelogram. You can achieve a rotation by performing 3 shear
  40.    operations on it. This is often given (as of this writing) as a good way
  41.    to do it, but I never tried. #4 is just plain faster.
  42.  
  43. 4) The method used by these programs is to scan the destination image
  44.    left to right/top to bottom, and at the same time scan the source image
  45.    by using rotated 'right' and 'down' vectors. This can be done extremely
  46.    fast by using fixed point math for the vectors and coordinates, and
  47.    eliminates the need to do any transformations. This method is faster than
  48.    the others and produces no holes in the destination image. It also allows
  49.    easy scaling of the bitmap at the same time (as do the other methods).
  50.  
  51. Sprites:
  52. --------
  53.   Most people want to rotate sprites, not do what these programs do. If you
  54.   understand the code, you can see that it isn't hard to adapt it to draw
  55.   sprites. I recommend storing them in a 256-wide image, so the 8.8 fixed
  56.   point calculations can be preserved. So what if thats wider than your
  57.   sprite... Put a couple side by side in the image. Also, the inner
  58.   loop will have to be modified so that it won't write the 'clear' parts
  59.   of the sprite to the destination image. This can be done by adding 2
  60.   instructions to the inner loop like so:
  61.  
  62.             mov  bl,[ds:bx]
  63.             or   bl,bl
  64.             jz   nodraw          <--  Add these 2 instructions
  65.             mov  [es:di],bl      <--  and label the 'inc' instruction
  66.   nodraw:   inc  di
  67.  
  68. This will slow things down a bit, but for actually doing sprites you'll 
  69. want to have it branch when it IS drawing a pixel, since that will probably
  70. happen LESS often. (a 16x16 sprite requires scaning a 27x27 pixel area to
  71. allow full rotation, and this extra area will all be clear.)
  72.  
  73.   I hope all this helps someone. I've already started writing a game with it
  74. and I can think of a few more that would be cool.
  75.  
  76. -Paul-
  77.  
  78. comments to---> phkahler@oakland.edu
  79.